2000/6/30 5:07
色々悩んだ挙げ句、ハタと気が
付いた。「unsigned short→unsigned int変換してから並べ替えたんじゃ、つじ
つまが合う訳ない！！」。つまり、
unsigned short [ab] → unsigned int[00ab] → Swap4[ba00]
全然ダメじゃん。と、言う訳でunsigned shortの状態でSwap()してから入れるよ
うにする事で、なんとか動くようになった。ホントは時間があれば、cache.srv
とかも入れたかったんだけど、もう時間が無いので諦めることにしよう。
今回は、ソース一式もsnapshotとして公開するつもりなので、その辺も準備しな
いといけない。はたして、間に合うのか？
2000/6/29
なんとか、dirコマンドが動作。しかし、ルートディレクトリィしか、ちゃんと
表示されない。追っかけてみると、どうやらFAT値がおかしい。これは、明かに
エンディアンの問題である。で、さっそくlowfnc.hで定義しておいたSwap2()マ
クロを使って補正したのだが、うまく動かない。困ったなぁ。昨日入れた画面ク
リアも動かないのが判っているので、そっちも直したいんだけど、時間が足りな
いかも。
2000/6/28 3:36
humanfs.srvのデバッグ。しかし、その為にはデバッグモードでチェックするの
が一番手っとり早い。で、カーネルのデバッグ出力をIOCSコールを使用している
部分を直接SCCを使用するようにする事で、デバッグモードを使用可能にした。
ついでに、通信速度を9600bpsに変更。どうせデバッグモードと言っても、垂れ
流しな訳なので、早いに越した事はないし。
しかし、なぜか「/sys/server/humanfs.srv: [_stdio.writeId == NULL]」が表
示される。で、よくよく考えてみると、標準入出力を初期化するUnixで言う所の
initが存在しないので、pshでも独自にconsole.srvを初期化しているのを思い出
した。けど、なんでhumanfs.srvが標準出力を使ってるんだ？
調べてみると、やっぱりデバッグ出力・・・。そろそろデバッグ環境も見直す時
期なのかもしれないが、時間が無いので後回し。取り敢えず画面に直接IOCSコール
で出すことでデバッグを続行する。一応、iocs.drvのテストも兼ねる事になるの
かな。ちゃんと動いているみたいではあるけど、まぁ、念のためだ。どっちにし
ろ、ちゃんとプリエンプティブになるまではiocs.drvの出番は無い訳だし。
あと、console.srvでのESCシーケンスの処理を若干追加。やっぱり画面クリア位
はサポートしてないと不便で仕方ないからね。
2000/6/27 4:23
iocs.drvは取り敢えず動いているようなので、今度は本命のhumanfs.srvの方に
取り掛かる。コアになるFATやディレクトリィの読み取りルーチンは別途テスト
プログラムを作成して、テスト済みなので動くのは判っているのだが、これを
サーバーにでっち上げる為には、このコア部分とサーバーとしてイベントループ
との隙間を埋めるコードを書かないといけない。色々と思うところはあるものの、
時間がないのでとにかく動くことを目標に進めて、なんとか実行ファイルを作成
出来た。んが、まともに動かん。まぁ、コンパイルを通っただけのプログラムが
一発で動く事ほど気味の悪い物はないので、別に問題はないけど、もうちょっと
動く素振りを見せてくれると有り難いんだけど。
シャープからHumanのシステムディスク等が公開されたので、こちらでもこれま
でFLOAT2.Xの差分として提供していたfloat2.drvを、そのままディスクイメージ
に入れることにした。おかげで、インストーラ（？）が更に簡単になった。
2000/6/26
む〜動かん。再びiocs.drvである。苦し紛れながら、_main.cを個別に持つこと
で、先日の問題はクリアしたハズなのだが・・・。デバッグモードにして実行経
過を調べてみたが、特におかしな所は見当たらない。いいかげん諦めようと思っ
た時に、フト思い付いた。
「カーネル内のデバッグ出力はIOCSコールを使ってねーか？」
と、言うことで取り敢えず、デバッグ出力を止めてみた所、あっけなく動作。
結構悩んだんだけどなぁ・・・
あと、ソースディレクトリィのdriver、server階層でのMakefileをちょっと効率
化。
2000/6/24
先日作成したiocs.drvをテスト。しかし、なんか実行時エラーが出てしまう。
はて？？？しかし、よくよく考えてみると、iocs.drvはpecls.knlの直後に起動
される。なのに、標準入出力を司るconsole.srvを使って表示とかをしようとし
ていた。そりゃ、エラーになるわな。けど、そうするとラインタイムライブラリ
を使わずにiocs.drvを構成させる必要があるな。ちょっと面倒かも。
2000/6/21
将来的にHumanのエミュレートを行う時に必要になる、IOCSコールをマルチタス
ク環境で使用できるようにするために、iocs.drvを作成した。このiocs.drvを組
み込む事で、IOCSコールをフックし、セマフォによる排他制御を行うようになる
ので、どのタスクからも任意の時点で呼び出す事が出来るようになる。ただ、現
状では、pecls側で動作しているデバイスドライバとの整合性は考えられてない。
ちゃんとやるには、IOCSコールに合わせてデバイスドライバへのメッセージに、
置き換える処理を盛り込む必要が有るだろう。
2000/5/31
ちょっと本業の方が忙しかったので、手を入れられなかった。最近、本腰を入れ
てやってないので、だいぶ何をやっていたのか判らなくなって来ている。まぁ、
その為にこれを書いてたりする訳なんだけどね。で、そうそう、seek処理を作成
中だったのだ。このseek処理でファイルの終端方向(順方向)に移動するのは、問
題無いのだが、ファイルの先頭方向(逆方向)への移動が曲者だったりする。
FATファイルシステムの特性として、順方向であればFATを辿れば移動できるのだ
が、逆方向への移動は無理なのだ。逆方向への移動が、どの程度の頻度で発生す
るかは判らないが、もし頻繁に使用されるのなら、内部的にファイルのFAT情報
を配列に保存しておくと言う手が考えられる。しかし、この方法だとファイルサ
イズに比例してメモリーが必要になるからなぁ。取り敢えず、先頭から再スキャ
ンするのが一番無難かな。
2000/5/12
更に間が空いて仕舞ったが、ちまちまと進行中。先日の状態だと、2階層以下の
ディレクトリィのファイルを、ちゃんとアクセスできなかった事が判ったので修
正。まだ、サーバープログラムのスケルトンへの組込みと言う作業が残っている
のだが、その前にファイルのseek/read/write処理を書かないとダメだな。
2000/4/19
なにやら妙に間が空いて仕舞ったが、なんとかファイルとディレクトリィのオー
プン処理が出来るようになった。ただ、マルチスレッド処理やイベントループへ
の組込みなどの部分は全然出来てなくて、フロッピーのイメージファイルをアク
セスできるようになっただけなので、あんまり進んでないのは確か。
もう少しまとまった時間を作って一気に仕上げたいんだけど、どうなることやら・・・
2000/3/16 0:55
と、言う訳で、至ってシンプルな方式でファイルを検索する処理を作成。3時間
程で、サブディレクトリィまで対応したファイルのオープン処理が、出来上がっ
てしまった。実際には今回作った処理に1つ関数をかぶせて、一般ファイル用と
ディレクトリィ用とに分ける必要が有るけど、それ自体はすぐに出来るだろう。
なんだかずいぶん時間が掛かってしまった様な気がするけど、なんとかhumanfs.srv
の形が見えて来たぞ。
2000/3/13
どひー。humanfs.srvのデバッグの続きなんだけど、動かない原因が判明。なん
と理由は単純で、
「ルートディレクトリィは、FATにリストが無い！！」
と言う半端な仕様が原因でした(涙)
これって、ディレクトリィの管理はルートディレクトリィの場合は、絶対に別処
理しないとダメって言う意味だよなぁ。ここまで作るまで気が付かなかったって
のも間抜けだけど、こんな変な仕様にした方も悪いと思わない？
・・・え？思わない？私が悪うございました。仕方無いので、根本的に処理手順
を見直す必要が有りそう(涙)
やっぱり、いきなり凝った事をしようとしたのが間違いの元かも。初心に帰って、
「動く事」を優先にもっとシンプルな方式で取り合えず作り直す事にしよう。
もったいないけど。
2000/2/24
loader.zでROMバージョンの判定が違ってたのを直した。それにしても、XVIcompact
が1.2だとは知らなかった・・・。
2000/2/20 22:07
humanfs.srvのディレクトリィ内部リスト部分を作成。はっきり言ってFATベース
の階層化ディレクトリィは効率的なキャッシュを行うのに向いてない。キャッシュ
を行わないのであれば、比較的シンプルにアクセス出来るのは確かなんだけど、
階層の深いファイルをアクセスする場合は、各階層毎にキャッシュを管理しない
といけないので、手間が掛かる。取り敢えず、基本構造は出来てきたので、後は
そのリストを使ってのファイルの検索処理と消費メモリー低減のための効果的な
キャッシュの解放処理だな。
2000/2/16 22:45
うーん。なんだか最近体力がなくて、仕事から帰って飯食ったら直ぐに眠くなっ
てしまう。と、言う訳で全然進んでなかったりする。取り合えずはhumanfs.srv
周りのソースをちまちま直したりしているものの、全く成果として出てくるレベ
ルにはなってない。humanfs.srvの基本的な関数はloader.zからの流用で行ける
ので、作り始めれば、そんなに手間は掛からないハズなんだけど・・・
2000/2/9 8:56
フトしたことでEX68上で起動出来ないことが判った。原因はIOCSコールのB_READ
の動作に違いが有るらしい。んが、詳しくは調べてない。もしかしたら、Human
以外のOSを起動出来るようには出来てないのかも。まぁ、この辺は気が向いたら
細かく調べることにしよう。
2000/2/6 1:48
Humanfs.srvを書きつつあるのだが、FATやディレクトリィ情報のキャッシュを何
処でやるかが問題である。少なくともFAT情報を全部メモリー上に持つのは、速
度的には有利である物の、古今の大容量ストレージを考えるとおそらく無理であ
る。ディレクトリィに関しては言うまでもなくメモリーには入りっこない。
一番単純な手法は、Humanfs.srvとデバイスドライバの間にCache.srvを置いて、
毎回ここに取得要求を出すと言う方法である。気になるのはタスク間通信のオーバ
ーヘッドではあるのだが・・・。さてどうしよう。
2000/1/9 2:25
何故か気が付いたら年が開けていた。ホントは年末年始の休みを利用してデバイ
スドライバを組むつもりだったのだが、ツーリングに行ってしまい、そっちの方
は全然手を付けられなかった。でも、scsi.drvの構想だけは立てたので、覚え書
きとして書いておこう。
scsi.drvはSCSI-ID毎のスレッドとSCSI-BUSを制御するスレッドの二階層で構成
し、SCSI-ID毎の受け付けスレッドからの要求を１つの制御スレッドのメイルボッ
クスに送信し、制御スレッドから結果が帰ってくるのを待つ。これにより、１つ
のSCSI-IDに対して複数の要求を同時に処理しないようにシリアライズする事が
できる（一次シリアライズ）。制御スレッドはメイルボックスから要求を取りだ
し、SCSIの制御を行う。ここで、処理が完結した場合は要求に対応する受け付け
スレッドに結果を返して、次の要求の処理を開始する。更に、処理未完了で
Disconnectが発生した場合（つまり一時的にターゲットがSCSI-BUSを解放した場
合）は、メイルボックスるから次の要求を取りだし、実行する。
処理完了後にReselectされた場合は、保留しておいた処理を続行して、結果が揃っ
た場合は、受け付けスレッドに返す。これにより、SCSI-BUSの空きに合わせて複
数のSCSI-IDに対する要求を処理できるようになる（二次シリアライズ）。
と、まぁ、構想だけは打ち立てたのだが、正月ボケのせいか、全然開発が進まな
いのである。こういう時は焦らずに気力を貯めてからやった方が効率が良いので、
充電しつつ構想を練ることにしよう。
1999/12/27 4:22
先日のミスを直してから、だいぶまともに動くようになってきた。でもって、こ
れまで最大の謎であった（笑）Test UnitがCheck Conditionになる原因が判りま
した。SCSIの規格書を良く読んでみると、ターゲットは電源投入時や、SCSIリセッ
ト時には、パワーオン・コンディションと言う状態を保持しており、Request Sense
で、最初に読みだす必要が有ったのでした。で、SCSIリセット後にRequest Sense
を発行することで、その他のコマンド類も動作するようになりました。
それから、マルチタスク環境で動作させる上で重要（かもしれない）Disconnect
への対応なんですが、Reselectの発生を旨く検出出来ないのです。本来ならReselect
割り込みが発生するのですが、現状のテストプログラムでは割り込みは使用せず
に、割り込み要因ビットをチェックしていたのだが、Reselectの時は、このビッ
トが設定されないらしい。SPCのマニュアルをひっくり返して調べたところ、ネ
クサスの状態をチェックすることで、Reselectされた事が検出出来る事が判明。
無事Disconnect/Reselectでやり取り出来る様になった。さて、この辺のノウハ
ウを元にデバイスドライバにしてみるかな。
1999/12/25 21:03
昨夜からMach2のテストプログラムを書いているのだが、なんだか動きがおかし
い。どーも、ステータスレジスタの値が変化しないみたいなのだ。色々調べたも
ののやっぱり判らずに、一度諦めて寝たのが11:00頃（爆）
でもって、夕方頃に再び起き出して、NetBSDのソースとかと見比べてみたりして
色々と試しているうちに、ふとSPCのレジスタアドレスが違うのでは？と言う疑
念が・・・。で、調べてみたら0x00ea0080でないといけないところが、0x00ea080
になってる（爆）をい。まじですかぁ？余りにも情けなさすぎる(;_;)
1999/12/25 4:45
某SCSIの仕事の関係もあり、良い機会なのでMach2を借りることにした。満開ネッ
トで貸し出してくれる奇特な方を募ったところ、某Y氏より借り受けることが出
来た。で、早速バイクで受け取りに行ってテスト用マシンに装着。
で、設定画面での設定可能項目を一通り見た後、簡単なプログラムを組んでROM
を吸い出してdisる（爆）ROMなので、当然シンボルテーブルなんか無いので、最
初は全然ソースにならない。なんか手間取りそうなので、こういう時の為に（笑）
移植しておいたdis for FreeBSDでdisとラベルファイルの編集を繰り返す事、数
時間。なんとかソースリストを得られた。この状態では内容はさっぱりなので、
めぼしい文字列なんかから意味の有るラベルを付けていくと、割り込みの登録や
ら、IOCSコールの登録なんかを見つけられた。ここまで来れば、後はそのコール
毎の処理を追っかける作業に入る。・・・と言う作業をやってました。別に遊ん
でた訳じゃないです。で、なんとかMach2p(なんとMach2ではなくMach2pが借りら
れたのです)に載っているMB86604Aのレジスタは0x00ea0080から32バイトに配置
されており、純正やSACOMのSCSIボードレジスタとはアドレスが違うのである。
ちなみに純正SCSIボードの石はMB89352で、レジスタは0x00ea0000からの32バイ
トなのだが、Mach2(p)の場合は、ここにアクセスするとバスエラーになるように
なっている様だ。なので、ここを見れば外付けSCSIが純正かMach2(p)か判断出来
る。更にROM内にはあちこちに「X680x0 Host Adapter mach2p」と言う文字列が
出てくるので、ここの「mach2p」に「p」が有るかどうかでMach2とMach2pが区別
出来るはずなのだ。と、言う訳で早速loader.zにその機能を組み込んでみた。
それにしても最近、ここの１回の文書量が多くなってきているのは気の所為か？
1999/12/18 1:50
先日の続きで、SCSIのテストプログラムを作成。Insideそのままのブロックを読
み込むだけから、更にTest Unitを発行出来るようになった。ちょっとハマった
のは、有りがちなgccの最適化によるやつで、
*HW_MB89352_INTS = *HW_MB89352_INTS;
とやっている部分だったりする。MB89352のINTSレジスタは、割り込み要因を保
持するレジスタなのだが、解除するためには、目的のビットを立てた値を入れる
必要がある。要するにXORなので、同じ値を入れてやれば全部クリア出来るのだ
が、gcc -Oだと、見事に最適化でその行を削除してくれたのです。判ってはいた
んだけど。で、例によって、
*HW_MB89352_INTS = *((volatile unsigned char*)HW_MB89352_INTS);
と、直すことであっさり動きました。
で、次にRead Capacityにチャレンジしたのだが、どうもうまく行かない。コマ
ンドフェーズまでは動いているのだが、データインフェーズでフェーズエラーに
なってしまう。はて？何が悪いのだろう。もう少し調べてみる必要が有りそうだ。
1999/12/15 1:52
humanfs.srvもやらないといけないと思いつつ、某SCSI機器の仕事の絡みも有っ
て、scsi.drvの方の基礎研究にも手を出すことに。いきなりドライバにするのは
例によって、なかなか難易度が高いので、まずはテストプログラムを作ることに
する。なにはともあれ、困った時のInside頼みと言うことで、InsideX68000を参
考にテストプログラムを作成してみる。うーむ。MB86604とMB89352は、かなり違
うなぁ。どっちかと言うとMB89352の方がシンプルで、扱い易い感じがする。まぁ、
確かに形式が違うんだけど、同じ富士通のSPCなんだから、なんで同じI/Fにして
ないの？理解に苦しむなぁ。それはともかく、このテストプログラムでノウハウ
を得て、scsi.drvと某SCSI機器で活用する予定である。
あと、scsi.drvだが、純粋なSCSIの制御とチップの制御を分離しようかどうかを
考え中。分離するとしたら、MB89352.drvとscsi.drvの組み合わせか、MB86604と
scsi.drvで使用する事になる。この場合、scsi.drvは共通で使用出来るので、一
応メリットは有る。さて、どうしたもんか。
1999/12/09 21:00
やはり、いきなりhumanfs.srvを作成するのは、色々と問題があるため、そのた
めの基礎研究として、FATファイルシステムのアクセスを行うテストプログラム
を作成する事にした。手始めに、先日検討したメモリー上でのデータ構造を単体
のヘッダーファイルに分離。それから、FATのアクセスとデマンド・ローディン
グ処理を書いてみた。面倒な処理になりそうだったFAT12でのページ境界でのセ
クタ番号の取り出しも、FATブロックのアクセス位置から必要なFATセクタを読み
込むような処理にすることで、解決出来た。
それから、フト思い付いたのだが、新にプリエンプティブになった時には、
float2.drvが問題になりそう。まだ、詳しくは見てないが、float2.drvはリエン
トラントでなかった様な気がするので、float2.drv入り口でセマフォでも付けて、
排他制御する必要があるな。そのうちやることにしよう。
1999/12/02 3:38
humanfs.srvの続き。と言うか、根本から見直し。手始めとして内部のデータ構
造のためのtypedefを定義。散々悩んだ挙げ句の答えは、内部データと読み込ん
だデータを両方保持する形式とした。でもって、FATの読み込み部分を書いてみ
た。それにしても12ビットFATの扱いって面倒。特にセクタ毎に別ブロックとし
て管理してしまったので、ブロックとブロックとの境界部分は特別扱しないとい
けない。なんか良い手はないもんか。
1999/12/01 2:46 LEVEL 4
はっきり言ってhumanfs.srvの方は、全く目処が立たないので、一度リリースす
ることにした。ただ、そのままだと流石にアレなので、最後のあがきとして、ローカ
ル・ヒープに対応した。ただ、ローカル・ヒープは、足りなくなるとタスクが動
かなくなってしまうので、ホントはマルチ・ヒープで有ることが望ましいと思う。
なので、この辺の詳細は暫定仕様と言う事になるのかな。
なにはともあれ、有る程度安定動作するようになったので、PECLS LEVEL-4をリ
リースします。前回のLEVEL 3からは約3ヶ月ぶりなのに、見た目も中身もあんま
り変わりばえしてないのが情けないっす。
1999/11/28 0:05
ここ数日別件（笑）で忙しかった、と言うか追い詰められていたので、こっちの
方は全然手を入れてなかったりする。でも、一応、構想だけは考えてました。
で、一番の悩み所はやっぱり現在作成中のhumanfs.srvのデータ構造である。
Human68kのファイルシステムは、基本的にMS-DOSと同じなFATによるファイルシ
ステムなので、FATとディレクトリィの管理が必要で、尚且つディレクトリィに
ついては階層化されている。これらの情報を独自の内部形式で保持すると、メモ
リー的に不利だし、クラスタ単位に整合すると言う面倒な作業が出てくる。
更に、既に削除されているファイルに対するディレクトリィの痕跡は、FAIL SAFE
として出来るだけ残しておくことが好ましいのに、それも困難になる。
逆にディスク上の形式そのままで保持する場合は、ディレクトリィ階層を保持す
るのが困難。と言うか内部的に欲しい作業領域を取る余地がないので、なんか面
倒な事になりそうなのである。それから、ファイルサーバーはファイルのオープ
ン毎に別スレッドを起動する事で効率的に動作させる予定なので、マルチスレッ
ドで動作する様にしておく必要がある。なので、内部データ構造はマルチスレッ
ド下でも破錠しないような形式または、破錠しないような対処が行える形式であ
る必要がある。と言う訳で、長々と書いてしまっているが、難しい問題が有るの
である。さて、どうするかなぁ・・・
1999/11/23 1:25
humanfs.srvの、と言うよりはPECLS OSのファイルサーバー汎用のパケットを検
討したのだが、以外とめんどくさい。一応、ユーザーサイドからはHuman FSでも、
PECLS FS（独自で作成する予定）でも区別する必要が極力無いようなファイルシ
ステムを目指しているのだが、欲張った分だけ色々と考慮することが増えてきて
しまった。なので、humanfs.srvが動き出すのは結構手間取りそうな予感である。
一応、仮仕様でディレクトリィ一覧が出来るまで持っていってL-4をリリースす
るつもりだが、そこそこの機能を盛り込んだhumanfs.srvが動き出すのは、年内
一杯掛かる気がする。それにしても、１年掛けてこの程度とは、我ながら情けな
い開発速度である。能力が足りないのもそうだけど、寄る年波には勝てないと言
うことか？（笑）
1999/11/22 0:10
ふと思い立って、humanfs.srvに手を付け始めた。とは言ってもFATファイルシス
テムについては、loader.zで既に前例があるので、そこから殆どの処理を持って
きて手直しすることで、主な部分は作成出来た。んが、ファイル名、ファイル属
性の扱いやら、マウントポイントの問題があるので、まだまだ完成には程遠いの
だけど。特に、マウントポイントに関しては、name.srvにも関係することなので、
仕様をどう決めるかが問題。おっと、ファイル名やファイル属性もFATファイル
システム専用でなくて、他のファイルシステムでも共通で使用出来る様な形式に
しないと、サーバーにした意味がないので、この辺も悩み所だな。
さて、humanfs.srvだが、ちゃんとしたものが出来るのには、まだまだ時間が掛
かるので、ディレクトリィ一覧が取れるようになったらL-4のリリースをするこ
とにしよう。なんとか、11月中にリリースしたいな。
1999/11/21 1:00
ついに原因を突き止めた。前にも書いたが、やっぱりメモリーの未初期化が原因
だった。まぁ、単純に言うとタスク情報領域のwup_tsk()の回数を覚えておく変
数領域を初期化していなかったために、起こされるハズのないslp_tsk()がSLEEP
せずに起床して仕舞ったため、念のために入れておいたexd_tsk()を実行して仕
舞っていたのでした。
で、exd_tsk()は、まだ実装してなかったので、未実装コール呼び出しの、エラー
が出ていたと言う訳。やっぱり、判ってしまえば単純なミスなのでした。
と、言う訳でメデタクpshまで動くようになりました。loader.zでのSCSIボード
の存在チェックが不十分だったのを修正。それと、MIDIボードのチェックも追加
してみただいぶ延期されていたけど、PECLS-L4のリリースを考えることにしよう。
問題は、何処まで盛り込むかだな。
1999/11/16 22:00
例によって動かない（涙）と、言う訳でちまちまとMakefileなんぞを整理してみ
る。調子に乗ってカーネルのbuild数を追加してみた。これまでの構築回数は覚
えてないので、今回がBuild numberの1と言う事になる。
それにしても、なんで動かないんだろう。ん？？？そー言えば、pshって随分長
いことmake掛けてなかったなぁ・・・っても、別に何かを変えた訳じゃないので
影響はないハズなんだけど、一応念のためチェックしてみるか。
1999/11/15 0:03
で、RAMチェックしてみました。もちろん正常。って、ゆーかぁー、Human68kが
動くんだから正常に決まってるんだけど（笑）
それはともかく、ブート・シーケンスを再検討していて、ふと気が付いたことが
ある。それは、ローダーを自己再配置の.r形式から.z形式に変更したのだが、そ
れだとbss領域が初期化されないのである。と、言う訳でipl.rにbss領域の初期
化処理を入れてみたのだが、結果は同じ（涙）一体何処が問題なんだろう？？？
それにしても、最近この手の原因不明のバグに悩まされっぱなしだなぁ。困った
困った・・・
1999/11/14 0:56
なんとなく動かない現象が見えてきた。少なくとも割り込みは無罪らしい。だっ
て、割り込みを使用しないカーネルでやっても同じ現象なので（笑）
で、現象だけど電源投入後、数回の起動でだけfloat2.drvの組み込みで、未定義
システムコール呼び出しのエラーが発生する。これは恐らくと言うかほぼ間違い
なく初期化してないメモリーをアクセスしているバグであろう。
でももし、バグでないならハード的にRAMが不安定と言う事になってしまう。
うーん。バグなんだろうなぁ。できればそう願いたいのだが。
1999/11/13 0:38
なんかMakefileがごちゃごちゃしてきたので、GNU makeの拡張機能と思われる
include機能を使って共通部分を共有する様にした。それと、原因は不明だが、
何度もインストールを重ねたFDだと、refreshしても動作が不安定になるので、
FDのフォーマット＆インストールを簡単に行うために、FDに入れる配置のディレ
クトリィを作成した。どっちにしろ、システムのディレクトリィ構成なんかもちゃ
んと決めないとだめだな。まぁ、ファイルサーバーが動くまでは、それ程急がな
いけど。
1999/11/5 23:02
色々デバッグコードを入れてみたり、コンパイルし直してみたりしているうちに
動くようになってしまった（爆）
でも、安定して動く訳じゃ無くて、立ち上げる度に動いたり動かなかったりなの
で、どっかタイミング的にマズイ所が有るのだろう。この手のタイミングの問題っ
てのは、見つけるのがなかなか難しい。なんと言ってもスナップ・ダンプやデバッ
ガとかでは見つけることが出来ないので、ソースとじっくりお見合いするか、設
計に問題がないか検討すると言う地味な作業をやらないといけない。
感じとしては、key.drv、text.drv、console.srv周りの初期化タイミングが怪し
いのだがどうだろう？
って、この手の予測は当たった試しが殆ど無いので、あんまりアテにはならない
んだけど(^^;;
1999/11/4 3:24
なんか非常に久しぶりなので、何処までやってたのかさっぱりである。と、言う
訳で適当にmakeかけてFDに実行イメージを作って動かしてみると、未定義コール
を実行したとか言って止まってしまう。はて？なんか変えたっけ？？？
どっちにしても、float2.drvは手を加えた記憶も、手を加える必要もないので、
問題があるとしたら、pecls.knlか、loader.zのどちらかしかない。
どっちかと言うとloader.zの方が怪しい気がするので、もうちょっとみてみよう。
1999/10/13 0:43
うーん。何処がおかしいのだろう。いつのまにかキー入力が出来なくなってしまっ
た。見当としては、key.drvのキー入力イベントの生成スレッドだと思うのだが、
どう見ても合っている様に見える。と、言うことはカーネルか？？？
どっちにしても、もっと突っ込んで調べてみないと駄目だろうな。と言う訳で３
歩進んで２歩下がると言う事を繰り返しているので、全然新しい機能に進めない
のであった（涙）
1999/10/12 9:38
昨夜はフェスタ68の手伝いの疲れの所為か、この開発記を書き掛けのまま忘れて
寝てしまった。と言う訳で、仕事に行く前に残りを書いていたりする。
プリエンプティブになるまでは、ディスパッチを禁止してもあんまり意味がない
のでテキストドライバのdis_dsp()/ena_dsp()をコメントアウト。
loader.zで、SCSIの装備状態を表示する様にした。これは、scsi.drv作成時まで
あんまり意味ないかも。ただ、Mach2pの量産が近い様なので、あんまりゆっくり
もしてられないな。
slp_tsk()で既にwup_tsk()が発行されていてもSLEEP状態になっていたバグを修
正。これによりタイミングによってはkey.drvが動作しなかった。
そろそろ、PECLS-L4を放流したいので、ちょっとまとめを始めた。
ん？もうこんな時間だぁ！！ああっ遅刻してしまう！！
1999/10/6 0:42
テスト用マシン(EXPERT)の修理に失敗。おかげでPECLSのテストのための開発マ
シンをいちいち再起動しなくてはならなくてタルすぎる。これはとっとと電源を
買ってくる必要があるな。
タスクのスタートアップでグローバルヒープとメッセージ用のヒープIDを受け渡
す様にした。タスクの異常終了なんかを考えるとタスク間でやり取りされるメッ
セージのためのメモリーは、タスクローカルから取るのは好ましくないので、グ
ローバルヒープから取れる様にするため、グローバルヒープのIDを受け取る様に
した。ただし、単純にグローバルヒープにした場合は、ヒープの断片化が心配な
ので、メッセージ専用のヒープを持つことを考えている。
あと、そろそろPECLS-L4のリリースも考える必要があるなぁ。9月はあんまり時
間が取れなかったので殆ど進んでないので10月末に持ち越すかな。
1999/10/5 0:11
余りにもファイルがデカくなってきたのでファイルを分けることにした。なんか
開発記じゃなくて雑記帳になりつつあるような気もしないでもないけどまあいい
や。読んでる人もあんまり居ないだろうし。
先日のloader.rの再配置処理の撤廃は完了した。loaderはCで書いてある関係上、
.r形式にするのはめんど過ぎるので、.x形式にしようと思ったが、どうせ固定ア
ドレスで動かすのなら、再配置テーブルとか読み込むのは無駄なので、.z形式と
言うことで落ち着いた。
.z形式で$c0000からとは言っても、.z形式のヘッダが付いたまま直接$c0000に読
み込むので実際の実行イメージは$c001cからと若干変則的になっている。注意さ
れたし。
それにしても1台のマシンで開発＆テストをするのは効率が悪すぎる。さっさと
ヒューズを買ってくることにしよう。